home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980424-19980901
/
000278_news@newsmaster….columbia.edu _Wed Jul 15 11:51:57 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA21502
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 15 Jul 1998 11:51:56 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA01387
for kermit.misc@watsun; Wed, 15 Jul 1998 11:51:56 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!jaltman
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problems w/ 115Kbps Direct Connect - k95xfer.gif (0/1)
Followup-To: poster
Date: 15 Jul 1998 15:51:54 GMT
Organization: Columbia University
Lines: 101
Message-ID: <6oij6q$mej$1@apakabar.cc.columbia.edu>
References: <35acb87b.1654633@149.174.211.108>
Reply-To: kermit-support@columbia.edu
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8979
In article <35acb87b.1654633@149.174.211.108>,
Ron Heiby <heiby_u@falkor.chi.il.us> wrote:
: I am having a problem with Kermit-95 1.1.17. I am seeing numerous CRC error,
: Retransmission, Bad Sequence Number, etc. errors on the file transfer.
: Sometimes, the transfer aborts. Sometimes it goes to completion and claims
: to be successful, but the file on disk is damaged.
:
: I am running over a direct serial cable between my desktop (Pentium) and
: notebook (486DX4/100). The desktop is running as "server". When I send from
: the notebook to the desktop, I have never seen a problem. When I send from
: the desktop to the notebook, I am seeing these problems.
:
: Both systems are running Windows 95. I have the serial ports set for 115200,
: mode local, modem none, flow rts/cts, handshake none, block check 3. Both
: using COM1 internal serial port. I have tried several receive packet lengths
: from 9024 down to 1500, and seen these failures. However, when I set the
: receive packet length to 1000, I have run about a dozen tests with no
: problem.
Sounds like one of the following:
. the laptop does not have a buffered UART
. the cable you are using does not have the proper flow control wires
. one of the UARTs is defective.
: I tried adding "set receive padding 94", but that seemed to have no effect
: on this problem.
This would have no impact on the problem.
: Sooooo... I guess I have a work-around: "set receive packet-length 1000"
: when operating at high speeds, at least until I replace my notebook with
: something faster.
That is the correct solution. Decrease the packet length and increase
the window size.
: Questions still remaining:
:
: 1) Why would I be seeing these problems? Is it some fundamental limitation
: of Win95? Could my serial port not have its buffering set properly? Does
: Kermit-95 set port buffering, or do I set it via Control Panel / System /
: Device Manager? I tried all four settings, but had problems on every one of
: them, so that doesn't seem to be it, at least by itself.
Port buffering is inherent to the serial device and may be controlled
on a system wide basis from the control panel. K95 does not attempt
to adjust the hardware settings of the device.
: 2) When these errors happen, why doesn't K95 realize what is going on, and
: refrain from putting garbage into the file? Why does it indicate successful
: completion of the transfer when there are bytes missing from the file? This
: one is most disturbing.
You would need to perform a comparison on the file to see what kind of
damage has occured. Kermit will notice if there is a damaged packet
such that the block check fails. However, if the file type is set
incorrectly a binary file will be damaged. Or a gif file may appear
to be damaged if it is truncated. Again, an examination of the source
and destination files would be necessary. If this problem is
reproducible we would also want to see debug and packet logs from both
sides of the connection so that we could fix the problem.
: 3) What the heck am *I* doing wrong (if anything)?
:
: Here is a screen capture of my Kermit-95 window from one of the more (but
: not completely) successful tests at packet size 8000. Note that K95 reports
: that the transfer was successful, but that the number of bytes listed in the
: success report does not match the file size. The number of bytes in the
: success report is the number K95 wrote to the file. The number of bytes in
: the file size is the number of bytes that are *supposed* to be in the file.
It sounds like K95 is detecting the failure and terminating the transfer
but printing the wrong message to the screen. What do these commands
report after an unsuccessful transfer:
SHOW STATUS -> should be FAILURE
STATISTICS -> should also report failure
: Thanks!
What does the other side of the connection report? Do they both agree
that the transfer was successful?
All followup to kermit-support@columbia.edu
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org